Telegram Group & Telegram Channel
Теперь немного подушним. За свою карьеру я-таки заметил одну вещь, от которой у меня пригорает. Многие разрабы не умеют в инкапсуляцию, от чего кишки классов и модулей часто вываливаются наружу.

Рассмотрим на примере. Представим что у нас есть вот такой класс:


class Disease {
var confirmed: Confirmed
}

enum class Confirmed {
YES, NO, NOT_SPECIFIED
}


Мы можем подтвердить диагноз или отклонить его. Как бы вы реализовали?
Нам обычно попадается такое:

fun setConfirmed(confirmed: Confirmed){
// какие-то проверки
this.confirmed = c
}


У такой реализации есть недостатки. Клиент теперь чуть больше знает о реализации вашего модуля: оказывается, есть какой-то енумчик, который нужно передать внутрь. Ещё это сложно рефакторить: как найти все места, в которых передается Confirmed.YES, учитывая что значение не везде передается константо? А если мы захотим поменять YES на CONFIRMED, сколько классов придется поправить? А можно ли передавать в метод NOT_SPECIFIED или же мы получим ошибку?

Пример примитивный, но объём кучи навоза уже можно прикинуть. И многие разработчики не думают, как грамотнее инкапсулироваться, вываливают всё наружу, а потом жалуются, что у них всё слиплось.

Правильнее сделать примерно так:

fun confirm(){
// какие-то проверки
this.confirmed = Confirmed.YES
}

fun decline(){
// какие-то проверки
this.confirmed = Confirmed.NO
}

fun confirmed() = this.confirmed == Confirmed.YES


Методов больше, но зато внешний клиент знает меньше про устройство модуля, мы легко можем найти все вызовы без угадайки. К тому же светить Enum может оказаться совсем необязательным, ибо с точки зрения предметки нас интересует только факт подтвержденности диагноза, а что там внутри за статусы — вообще пофигу.

Но это ладно, когда мы знаем какой параметр передать, — это самый легкий случай. Иногда нужно знать последовательность вызовов или даже тайминг. Вообще, степень такой связности обозвали даже специальным словом Connascence.

Поэтому, когда вы пишете модуль, подумайте над следующим:
- Что вы можете скрыть и не показывать?
- Какие изменения внутри вашего модуля могут затронуть клиента?
Вы удивитесь, насколько проще клиенту будет работать с вашим модулем.



tg-me.com/stringconcat/226
Create:
Last Update:

Теперь немного подушним. За свою карьеру я-таки заметил одну вещь, от которой у меня пригорает. Многие разрабы не умеют в инкапсуляцию, от чего кишки классов и модулей часто вываливаются наружу.

Рассмотрим на примере. Представим что у нас есть вот такой класс:


class Disease {
var confirmed: Confirmed
}

enum class Confirmed {
YES, NO, NOT_SPECIFIED
}


Мы можем подтвердить диагноз или отклонить его. Как бы вы реализовали?
Нам обычно попадается такое:

fun setConfirmed(confirmed: Confirmed){
// какие-то проверки
this.confirmed = c
}


У такой реализации есть недостатки. Клиент теперь чуть больше знает о реализации вашего модуля: оказывается, есть какой-то енумчик, который нужно передать внутрь. Ещё это сложно рефакторить: как найти все места, в которых передается Confirmed.YES, учитывая что значение не везде передается константо? А если мы захотим поменять YES на CONFIRMED, сколько классов придется поправить? А можно ли передавать в метод NOT_SPECIFIED или же мы получим ошибку?

Пример примитивный, но объём кучи навоза уже можно прикинуть. И многие разработчики не думают, как грамотнее инкапсулироваться, вываливают всё наружу, а потом жалуются, что у них всё слиплось.

Правильнее сделать примерно так:

fun confirm(){
// какие-то проверки
this.confirmed = Confirmed.YES
}

fun decline(){
// какие-то проверки
this.confirmed = Confirmed.NO
}

fun confirmed() = this.confirmed == Confirmed.YES


Методов больше, но зато внешний клиент знает меньше про устройство модуля, мы легко можем найти все вызовы без угадайки. К тому же светить Enum может оказаться совсем необязательным, ибо с точки зрения предметки нас интересует только факт подтвержденности диагноза, а что там внутри за статусы — вообще пофигу.

Но это ладно, когда мы знаем какой параметр передать, — это самый легкий случай. Иногда нужно знать последовательность вызовов или даже тайминг. Вообще, степень такой связности обозвали даже специальным словом Connascence.

Поэтому, когда вы пишете модуль, подумайте над следующим:
- Что вы можете скрыть и не показывать?
- Какие изменения внутри вашего модуля могут затронуть клиента?
Вы удивитесь, насколько проще клиенту будет работать с вашим модулем.

BY StringConcat - разработка без боли и сожалений


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/stringconcat/226

View MORE
Open in Telegram


StringConcat разработка без боли и сожалений Telegram | DID YOU KNOW?

Date: |

The SSE was the first modern stock exchange to open in China, with trading commencing in 1990. It has now grown to become the largest stock exchange in Asia and the third-largest in the world by market capitalization, which stood at RMB 50.6 trillion (US$7.8 trillion) as of September 2021. Stocks (both A-shares and B-shares), bonds, funds, and derivatives are traded on the exchange. The SEE has two trading boards, the Main Board and the Science and Technology Innovation Board, the latter more commonly known as the STAR Market. The Main Board mainly hosts large, well-established Chinese companies and lists both A-shares and B-shares.

Telegram Gives Up On Crypto Blockchain Project

Durov said on his Telegram channel today that the two and a half year blockchain and crypto project has been put to sleep. Ironically, after leaving Russia because the government wanted his encryption keys to his social media firm, Durov’s cryptocurrency idea lost steam because of a U.S. court. “The technology we created allowed for an open, free, decentralized exchange of value and ideas. TON had the potential to revolutionize how people store and transfer funds and information,” he wrote on his channel. “Unfortunately, a U.S. court stopped TON from happening.”

StringConcat разработка без боли и сожалений from ca


Telegram StringConcat - разработка без боли и сожалений
FROM USA